Services versioning

ABSTRACT

Downloadable pluggable services and methods of distributing the same are described. The downloadable pluggable services may correspond to communication services that can be downloaded to upgrade a communication system. The downloadable pluggable services may include a number of component parts that can be distributed among various servers in the communication system being upgraded along with instructions that enable the component parts to instruct each server in the communication system to operate in a coordinated fashion so as to provide the downloaded service.

CROSS REFERENCE TO RELATED APPLICATION

The present application is a continuation of U.S. patent applicationSer. No. 15/815,333, filed on Nov. 16, 2017, now U.S. Pat. No.10,560,551, which is a continuation of U.S. patent application Ser. No.15/017,338, filed Feb. 5, 2016, now U.S. Pat. No. 9,826,062, which is acontinuation of U.S. patent application Ser. No. 13/624,923, filed Sep.22, 2012, now U.S. Pat. No. 9,262,150, and (b) U.S. patent applicationSer. No. 14/985,013, filed Dec. 30, 2015, now U.S. Pat. No. 9,826,061,entitled “SERVICES VERSIONING”, each of which is incorporated herein bythis reference in its entirety.

FIELD OF THE DISCLOSURE

The present disclosure is generally directed toward communications andmore specifically toward communication systems and methods.

BACKGROUND

Communication systems have been developed to deliver modularapplications that are sequenced or named as part of normal callsignaling. The promise to these systems is that many applications can bewritten for a variety of solution spaces. Heretofore, an applicationserver has only been able to provide one sophisticated application withreleases that occur, at best, on a semi-annual basis.

In most communication systems, call treatment features are currentlyprovided by a single, monolithic feature server. Adding a new orupgrading an existing call treatment feature on a server requires a newversion of software and requires the customer to upgrade the entireserver. Such upgrades can cause operational downtime and can haveimpacts that are not limited to users of the new/upgraded feature. Inother words, current communication systems do not enable convenientsystem upgrades nor do they enable simple upgrades on a per user basis.

To achieve more rapid development, an ecosystem that allows for theindependent development and deployment of applications is desired.

SUMMARY

It is with respect to the above issues and other problems that theembodiments presented herein were contemplated. In particular,embodiments of the present disclosure propose the ability to, amongother things, allow different users of the same communication system tohave different services and different versions the same service madeavailable to them. Specifically, different subsets of users can havedifferent services and/or service versions made available to them wherethe services include, for instance, a call processing piece, userinterface piece, and management piece.

In some embodiments, this is made possible by the fact that acommunication system administrator can download a new service or newversion of an existing service and the necessary portions of thatservice or version are installed at the appropriate devices in thecommunication system. The administrator can then assign the new serviceor service version to specific users or groups of users, but excludeother users or groups of users.

One advantage of the present disclosure is that a new version of aservice can be tested-out on a single user rather than testing the newversion of the service system-wide as is currently required. Because thenew version of the service can be slowly rolled out (e.g., for a singleuser at a time), there is a much smaller impact associated with serviceupgrades. Furthermore, the bugs can be worked out for a small group ofusers before upgrading all users of the system.

It is another aspect of the present disclosure to provide the ability tohave a hot deploy (no downtime during the upgrade) of a new serviceversion or a completely new service.

As one example of a hot deployment of a service, a user that receives anupgrade may have that upgrade assigned to them during a call and theupgrade will be completed in the background during the call such thatonce the user is done with the call, the new service is readilyavailable. In particular, the upgrade process enables each component ofthe new service to be distributed to the appropriate component andinstalled, without replacing the previous version of the same service.Therefore, if the service happens to be deployed while an affected useris in the middle of a call, the affected user will continue that callusing the old service version. After, the user has completed the call,the user will have access to the new version of the service.

Furthermore, a service can be assigned to a small set of users. When itbecomes desirable to move the service to a bigger group of users, allthat is required is to change permissions for the newly-assignedindividuals. There is no need to deploy any further software on everyuser's device and, again, this can be done during runtime.

As can be appreciated, a new service should be considered an upgrade ofthe existing overall general functionality. Therefore, embodiments ofthe present disclosure cover both upgrades to existing services as wellas new services.

In some embodiments, a pluggable service includes a call-processingcomponent, a user component, a management component, and a templatecomponent. In some embodiments, the “template component” is what getsadded to/plugged into the existing templates based on the newservice/version. As used herein, a template may comprise multipletemplate components, where each template component corresponds todifferent deployed service or service version. Administrators create oneor more templates with specific services enabled and specificconfiguration settings for those services. By creating this template andassigning it to one or more users, the administrator is able to controlexactly what services and settings each user receives. Therefore, theadministrator gets to select a service version or groups of serviceversions on behalf of the user.

If an administrator defines, via the templates, that a user is allowedto have one of multiple different service versions, then the user may beallowed to select which service version he/she uses. In this example,the templates allow the system administrator to define which versions auser is allowed to use and the users can then select which specificversion of a service they actually use via the user interface component.

In some embodiments, a pluggable service may have its differentcomponents packaged into a specific file format such as a JAR or WARfile. For instance, a Dynamic Device Pairing (DDP) ‘service’ jar mayinclude a call processing piece, a service rule piece, a userportal/interface piece, the system manager's or administrator's piece,and perhaps other components (e.g., country specific components,language components, etc.). Instead of including all possiblesub-components (e.g., all skins, all languages) into the overall servicejar, the user could pick and chose the ones he/she wants, resulting in avery specialized service. For instance, if the user wants a Swedish lookand feel to their user portal, he/she could specify that when orderingthe overall service, and the entity which distributes the service wouldbuild the service with only that skin. Other pieces could be changed aswell, for example, the service rule. Dynamic customization allows aservice to have multiple personalities that can be tailored toindividual customers. The customer might want to affect that behavior aswell.

Other aspects of the present disclosure include the ability for anindependent party to develop localization packages for the customer todownload as well as the concept of pluggable licensing.

Here the customer or system administrator would be able to specifycustomization of a pluggable service at ordering time (e.g., how manyusers can use the service, which users will use the service, etc.). Itmay also be possible to include the license in the service (or differentsub-components of the service) and dynamically create the appropriatebundle at ordering time.

Another aspect of the present disclosure is that there may be dataattributes defined by or for a service. In some embodiments, eachattribute has the listed levels in the hierarchy and a factory defaultmay be used. Administrators and users are allowed to configure this samedata. In general, the user configured value will override the adminvalue, but the administrator can specify that a certain piece of data isnot user-configurable or only user-configurable within a predeterminedrange.

Yet another aspect of the present disclosure is to avoid the need to usea substantial amount of html code to paint or render a screen for a userin connection with providing a service. In particular, an eXtensibleMarkup Language (XML) can be used to define the data that will bemanipulated by a system administrator or user. The html code can bepre-stored on a system manager of the communication system. The updatesprovided by a pluggable service only has to define, in an abstractlanguage, what data the html code is required to look at and then thehtml code is used to look at the abstract language to perform thedefined functions.

Because the attribute definitions describing what is going to bedisplayed requires less code-space than the html code itself, thepluggable service can be kept at a minimal size. Another benefit is easeof development of a new service. For example, only data elements need tobe defined, rather than developing, testing, and delivering html code.

In accordance with at least some embodiments of the present disclosure,a method is provided which generally comprises:

a. receiving a request from a customer to obtain a downloadablepluggable service for a communication system of the customer;

b. in response to receiving the request, preparing the downloadablepluggable service, wherein preparing the downloadable pluggable serviceincludes obtaining a first and second sub-component that are packagedinto a single object, wherein the first sub-component includesinstructions for operating a first server of the customer'scommunication system, and wherein the second sub-component includesinstructions for operating a second server of the customer'scommunication system; andc. transmitting the single object to the customer.

In accordance with at least some embodiments of the present disclosure,a method is provided which generally comprises:

a. providing a communication system to a plurality of users;

b. defining, for a first user, or group of users, in the plurality ofusers, a first set of enabled services that the first user, or group ofusers, is allowed to access from the communication system;

c. defining, for a second user, or group of users, in the plurality ofusers, a second set of enabled services that the second user, or groupof users, is allowed to access from the communication system, whereinthe first set of enabled services differs from the second set of enabledservices by at least one service; andd. enforcing the first and second sets of enabled services for the firstand second users, or group of users, use of the communication system.

In accordance with at least some embodiments of the present disclosure,a method is provided which generally comprises:

a. receiving a service for a first user; and

b. loading the service for the first user onto one or more serverswithout requiring the first user to log off or discontinue acommunication session.

Although embodiments of the present disclosure will be primarilydescribed in connection with communication services or communicationsystems, it should be appreciated that “services” as used herein caninclude any type of feature or feature set that is made available to auser or group of users either within a single enterprise or withinmultiple enterprises. Non-limiting examples of services includecommunication services (e.g., call routing services, call-enhancingfeatures, conferencing services, security/encryption services, firewallservices, multi-media communication services, collaboration services,etc.), http-type services (e.g., web-browsing services,web-collaboration services, etc.), media services, data storageservices, and any other service that can be supported or provided by aserver or collection of servers that provide users or client deviceswith content or features to enhance operations of the client device orsystems exposed to the client device.

Furthermore, the term “server” as used herein should be understood toinclude any server, collection of servers, processors within a server,blades within a server, one or more virtual machines being executed by aserver, containers or processes being executed by a server, etc. Inother words, “servers” are not necessarily limited to individualhardware components with dedicated processors and memory. “Servers” arealso not limited to a particular type of container executed by a server,such as a J2EE server or any other version of a Java EE server.Non-limiting examples of containers that may be executed by orconstitute a server include application containers (e.g., Java VirtualMachines), applet containers (e.g., web browsers or applet viewers),Enterprise JavaBeans (EJB) containers, web containers, ApplicationProgramming Interfaces (APIs), and the like.

The phrases “at least one”, “one or more”, and “and/or” are open-endedexpressions that are both conjunctive and disjunctive in operation. Forexample, each of the expressions “at least one of A, B and C”, “at leastone of A, B, or C”, “one or more of A, B, and C”, “one or more of A, B,or C” and “A, B, and/or C” means A alone, B alone, C alone, A and Btogether, A and C together, B and C together, or A, B and C together.

The term “a” or “an” entity refers to one or more of that entity. Assuch, the terms “a” (or “an”), “one or more” and “at least one” can beused interchangeably herein. It is also to be noted that the terms“comprising”, “including”, and “having” can be used interchangeably.

The term “automatic” and variations thereof, as used herein, refers toany process or operation done without material human input when theprocess or operation is performed. However, a process or operation canbe automatic, even though performance of the process or operation usesmaterial or immaterial human input, if the input is received beforeperformance of the process or operation. Human input is deemed to bematerial if such input influences how the process or operation will beperformed. Human input that consents to the performance of the processor operation is not deemed to be “material”.

The term “computer-readable medium” as used herein refers to anytangible storage that participates in providing instructions to aprocessor for execution. Such a medium may take many forms, includingbut not limited to, non-volatile media, volatile media, and transmissionmedia. Non-volatile media includes, for example, NVRAM, or magnetic oroptical disks. Volatile media includes dynamic memory, such as mainmemory. Common forms of computer-readable media include, for example, afloppy disk, a flexible disk, hard disk, magnetic tape, or any othermagnetic medium, magneto-optical medium, a CD-ROM, any other opticalmedium, punch cards, paper tape, any other physical medium with patternsof holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, a solid state mediumlike a memory card, any other memory chip or cartridge, or any othermedium from which a computer can read. When the computer-readable mediais configured as a database, it is to be understood that the databasemay be any type of database, such as relational, hierarchical,object-oriented, and/or the like. Accordingly, the disclosure isconsidered to include a tangible storage medium and prior art-recognizedequivalents and successor media, in which the software implementationsof the present disclosure are stored.

The terms “determine”, “calculate”, and “compute,” and variationsthereof, as used herein, are used interchangeably and include any typeof methodology, process, mathematical operation or technique.

The term “module” as used herein refers to any known or later developedhardware, software, firmware, artificial intelligence, fuzzy logic, orcombination of hardware and software that is capable of performing thefunctionality associated with that element. Also, while the disclosureis described in terms of exemplary embodiments, it should be appreciatedthat individual aspects of the disclosure can be separately claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is described in conjunction with the appendedfigures:

FIG. 1 is a block diagram of a first communication system in accordancewith embodiments of the present disclosure;

FIG. 2 is a block diagram of a service warehouse in accordance withembodiments of the present disclosure;

FIG. 3 is a block diagram of a second communication system in accordancewith embodiments of the present disclosure;

FIG. 4 is a block diagram of a third communication system in accordancewith embodiments of the present disclosure;

FIG. 5 is a block diagram of a fourth communication system in accordancewith embodiments of the present disclosure;

FIG. 6 is a block diagram of a deployable object in accordance withembodiment of the present disclosure;

FIG. 7 is a block diagram depicting a service template in accordancewith embodiments of the present disclosure;

FIG. 8 is a block diagram depicting a data structure used in connectionwith administering services in accordance with embodiments of thepresent disclosure;

FIG. 9 is a flow diagram depicting a method of delivering a downloadableobject in accordance with embodiments of the present disclosure;

FIG. 10 is a flow diagram depicting a method of deploying and installinga downloadable object in accordance with embodiments of the presentdisclosure;

FIG. 11 is a flow diagram depicting a method of customizing adownloadable object in accordance with embodiments of the presentdisclosure;

FIG. 12 is a flow diagram depicting a method of deploying a serviceduring system run-time in accordance with embodiments of the presentdisclosure;

FIG. 13 is a flow diagram depicting a method of upgrading a service inaccordance with embodiments of the present disclosure; and

FIG. 14 is a flow diagram depicting a method of hierarchicallystructuring attributes for a service in accordance with embodiments ofthe present disclosure.

DETAILED DESCRIPTION

The ensuing description provides embodiments only, and is not intendedto limit the scope, applicability, or configuration of the claims.Rather, the ensuing description will provide those skilled in the artwith an enabling description for implementing the embodiments. It beingunderstood that various changes may be made in the function andarrangement of elements without departing from the spirit and scope ofthe appended claims.

FIG. 1 shows an illustrative embodiment of a communication system 100 inaccordance with at least some embodiments of the present disclosure. Thecommunication system 100 may be a distributed system and, in someembodiments, comprises one or more communication networks 104 thatfacilitate communications between a service warehouse 108 and one ormore customers or customer sites 112 a-N.

The communication network 104 may be packet-switched and/orcircuit-switched. An illustrative communication network 104 includes,without limitation, a Wide Area Network (WAN), such as the Internet, aLocal Area Network (LAN), a Personal Area Network (PAN), a PublicSwitched Telephone Network (PSTN), a Plain Old Telephone Service (POTS)network, a cellular communications network, an IP Multimedia Subsystem(IMS) network, a SIP network, a Voice over IP (VoIP) network, orcombinations thereof. In one configuration, the communication network104 is a public network supporting the TCP/IP suite of protocols.Communications supported by the communication network 104 includereal-time, near-real-time, and non-real-time communications. Forinstance, the communication network 104 may support voice, video, text,web conferencing, or any combination of media.

The service warehouse 108 may provide a location where customers 112 a-Ncan view and ultimately purchase services. Examples of services that maybe offered by the service warehouse 108 include communication services,media services, management services, data storage services, processingservices, combinations thereof, and any other automated orcomputer-implemented service. In some embodiments, the service warehouse108 may provide access to its services via one or more web pages servedby a web server or group of web servers. The service warehouse 108 mayprovide customers 112 a-N with the ability to view various servicesoffered by the service warehouse 108 though known web-basedcommunication protocols (e.g., http, secure http, etc.). The customers112 a-N may comprise one or more client devices with a web-browserapplication executed thereon that allows user or system administratorsat the customer site to view and purchase services from the servicewarehouse 108.

As will be discussed in further detail herein, the service warehouse 108may comprise the functionality to receive an order for one or moreservices from a customer 112 a-N, automatically prepare one or moredownloadable pluggable services, and send the downloadable pluggableservices to the ordering customer 112 a-N via the communication network104. In some embodiments, the service warehouse 108 may provide theordered service(s) to the customer 112 a-N via the same or similarprotocol used by the customer 112 a-N to order the service(s). It mayalso be possible for the service warehouse 108 to provide the orderedservice(s) to the customer 112 a-N in the same communication sessionduring which the order was received. In other words, the servicewarehouse 108 may deliver the ordered service(s) via the same portnegotiated during the web-based communication session that was used toorder the service(s). This provides a simple and efficient way ofdelivering services from the service warehouse 108 to the customer 112a-N.

It should be appreciated that the service warehouse 108 may bedistributed. Although embodiments of the present disclosure will referto a single service warehouse 108 as the mechanism by which services aredelivered to customers, it should be appreciated that the embodimentsclaimed herein are not so limited. For instance, multiple servicewarehouses 108 may be executed by multiple different servers in eitheran autonomous or coordinated fashion. One customer may communicate withone instance of the service warehouse 108 whereas another customer maycommunicate with another instance of the service warehouse 108.

With reference now to FIG. 2, additional details of a service warehouse108 will be described in accordance with embodiments of the presentdisclosure. A service warehouse 108 may comprise a customer portal 208,an object delivery interface 212, an object generator 216, and an objectsub-component library and repository 220. Although the customer portal208 and object delivery interface 212 are depicted as being separate anddistinct components, which they may be, it should be appreciated thatsome instances of a service warehouse 108 may comprise a singlecomponent that acts as both a customer portal 208 and object deliveryinterface 212.

The customer portal 208 provides the service warehouse 108 with theability to expose available services to customers 112 a-N as well asreceive orders for services from customers 112 a-N. In some embodiments,the customer portal 208 may comprise a web interface (e.g., one or moreweb pages configured to be provided to the customer 112 a-N via a markuplanguage, for example), a web server, a group of web servers, acommunication port, a communication socket, or any other combination ofhardware and/or software components that enable a customer 112 a-N toremotely view contents of the service warehouse 108.

More specifically, the customer portal 208 may enable a customer 112 a-Nto view contents of the object sub-component library and repository 220or a listing of services that can be provided to the customer 112 a-Nvia sub-components 228 listed within the sub-component library 224 andstored in the object sub-component library and repository 220. Somenon-limiting examples of services that can be displayed to a customer112 a-N via the customer portal 208 and, therefore, ordered by thecustomer include one or more communication services such as a voicemailservice, a call-forwarding service, a dynamic device pairing service, acall-routing service, an extension to cellular service, a speech-to-textservice, a text-to-speech service, a call-recording service, a medialibrary, an Interactive Voice Response (IVR) service, a conferencingservice, or the like.

While the customer portal 208 enables a customer 112 a-N to view andorder services, the object generator 216 is responsible for fulfillingservice orders. Specifically, if a customer 112 a-N places an order fora particular service or set of services, the object generator 216 isinvoked to gather the necessary sub-components 228 from the objectsub-component library and repository 220 and bundle the sub-components228 into an object that is deliverable directly to the customer 112 a-Nvia the communication network 104. Even more specifically, when theobject generator 216 receives an order for a service, the objectgenerator 216 is configured to determine the type of service that hasbeen ordered and also determine which sub-components 228 will berequired to ultimately provide the ordered service to the orderingcustomer. It should be appreciated that the number and type ofsub-components 228 required to provide a particular service to aparticular customer may depend upon the type of equipment being used bythe customer, the nature of the ordered service, the number of licensesof the service that have been ordered (e.g., how many users at thecustomer site will use the service), and a number of other factors.

In some embodiments, an object may be custom built by the objectgenerator 216 to accommodate one or more customer-specific requests forthe service. As a non-limiting example, assume that a customer has justordered a new communication service that will have a number ofsub-components such as a user portal sub-component, a call-processingsub-component, an administrative or system management sub-component, anda user interface sub-component. One or more of these sub-components maybe customized by the object generator 216 to accommodate the specificversion of the servers (or processors) that will ultimately execute eachsub-component as well as accommodate any special requests made by theordering customer (e.g., language requests, look-and-feel requests,default rules/preferences, etc.). The object generator 216 is capable ofretrieving the appropriate sub-components 228 by referring to thesub-component library 224 and, from that sub-component library 224,determining which sub-components 228 will properly provide the servicethat has been ordered by the customer.

One non-limiting example of an object 604 that may be generated by theobject generator 216 is depicted in FIG. 6. As discussed above, theobject 604 created by the object generator 216 may comprise one or moresub-components that will enable various different servers at thecustomer's premises to operate in a coordinated fashion to provide theordered service. Some examples of sub-components that may be included inan object 604 used to deliver a communication service include, withoutlimitation, a user portal sub-component 608, a call-processingsub-component 616, and a system manager sub-component 620. Although notdepicted, the object 604 may also comprise a license sub-component thatdefines the customer's entitlements for using the service (e.g., thenumber of users that can be assigned the service). The object 604generated by the object generator 216 may also include deploymentinstructions 612 that, when followed, will enable the successfuldeployment of the object 604 at the customer's premises by distributingthe sub-components to the appropriate locations/servers.

It should be appreciated that the sub-components 228 may be stored inmemory of the service warehouse 108 as files, executables, or the likeand the sub-component library 224 may simply correspond to a listing ortable of the various sub-components 228 stored in memory. Thesub-component library 224 may also provide links or addresses that canbe used by the object generator 216 to locate and retrieve thecorresponding sub-components 228 from memory. In other words, thesub-component library 224 may include a listing of sub-components 228 aswell as indexing mechanisms used to locate the sub-components instorage.

The object delivery interface 212 of the service warehouse 108 providesthe object generator 216 with the ability to deliver the object 604 to acustomer 112 a-N via the communication network 104. In some embodiments,the object delivery interface 212 may occupy the same hardwarecomponents (e.g., socket, port, network interface card, etc.) as thecustomer portal 208. In some embodiments, the object delivery interface212 is different from the customer portal 208. In either implementation,the object delivery interface 212 may be configured to package orencapsulate the object 604 generated by the object generator 216 intoone or more communication packets or files that are deliverable over thecommunication network 104. The object delivery interface 212 may alsocomprise the capability to locate and transmit the object 604 to theordering customer.

With reference now to FIG. 3, additional details of an illustrativecustomer premises 304 will be described in accordance with embodimentsof the present disclosure. The customer premises 304 may, in someembodiments, correspond to an enterprise network that is owned andoperated by a single customer 112. In other words, a single customer 112may own, lease, or otherwise solely control the operation and/ormaintenance of the communication devices contained within the boundariesof the customer premises 304. Such a customer premises 304 is commonlyreferred to as an enterprise network. The enterprise network may bedistributed (e.g., a WAN) or it may be confined to a single location(e.g., a LAN). In other embodiments, multiple customers 112 a-N sharesome or all of the components of the customer premises 304.

The premises 304 may correspond to an enterprise network and, in someembodiments, may comprise a network boundary device 308 that includes aserver table 312, a communication server 316, one or more servers 336(e.g., application servers, feature servers, etc.) capable of providingone or multiple services to users, one or more internal communicationdevices 348, a data store 352, one or more user portal servers 356, oneor more system manager servers 364, and one or multiple other servers372. Some or all of the components of the premises 304 may beinterconnected by a (trusted or secure or private) Local Area Network(LAN) 344. Some or all of the functions depicted in FIG. 3 may beco-hosted and/or co-resident on a single server. The depiction ofcomponents in FIG. 3 and the other figures provided herein are generallyintended to be a logical depiction of the components of the system. Itshould be appreciated that an enterprise network or multiple enterprisenetworks may comprise multiple LANs 344 connected via a WAN, such as thecommunication network 104. A single enterprise communication network 304is depicted in FIG. 3 and described herein for ease of understanding andsimplicity and in no way is intended to limit embodiments of the presentinvention to a single enterprise network 304.

The LAN 344 can be secured from intrusion by untrusted parties by agateway and/or firewall located between the LAN 344 and communicationnetwork 104. In some embodiments, the boundary device 308 may includethe functionality of the gateway and/or firewall. In some embodiments, aseparate gateway or firewall may be provided between the boundary device308 and the communication network 104.

Although only a single instance of each server (e.g., a singlecommunications server 316, a single application server 336, a singleuser portal 356, and a single system manager 364) is depicted in FIG. 3,two or more instances of any server type may be provided in a singleenterprise network 304 or across multiple separate LANs 344 owned andoperated by a single enterprise, but separated by communication network104. In configurations where an enterprise or an enterprise network 304includes two or more servers of a single type (e.g., multiplecommunication servers 316), each server may comprise similarfunctionality, but may be provisioned for providing its features to onlya subset of all enterprise users. In particular, as a non-limitingexample, a first communications server 316 may be authoritative for andservice a first subset of enterprise users whereas a secondcommunications server 316 may be authoritative for and service a secondsubset of enterprise users, where the first and second subsets of usersgenerally do not share a common user. This is one reason why the networkboundary device 308 may be provided with a server table 312—the servertable 312 may comprise the information that maps a user to theirauthoritative communication server 316.

Additionally, multiple servers can support a common user community. Forexample, in geo-redundant and other applications where users aren'tnecessarily bound to a single application server, there may be a clusterof equivalent servers where a user can be serviced by any server in thecluster.

The communications server 316 can include a Private Branch eXchange(PBX), an enterprise switch, an enterprise server, components orapplications executed within a server, a virtual machine provided by aserver, combinations thereof, or other type of telecommunications systemswitch or server. The communication server 316 is, in some embodiments,configured to enable the execution of telecommunication functions suchas the suite of applications and services made available via Avaya Aura™platform of Avaya, Inc., including Communication Manager™, Avaya AuraCommunication Manager™, Avaya IP Office™, Communication Manager Branch™,Session Manager™, MultiVantage Express™, and combinations thereof.

In accordance with at least some embodiments of the present disclosure,the mapping of user identities within a communication request does notnecessarily have to occur at the network boundary device 308. Forinstance, the mapping between an authoritative communication server 316and a user may occur “behind” the network boundary device 308 within theenterprise network 304. In some embodiments, the network boundary device308 may include functionality similar to a Session Border Controller(SBC), a firewall, gateway, or any other device that provides securityand/or translation capabilities.

In some embodiments, network boundary device 308 is responsible forinitially routing communications within the enterprise network 304 tothe communications server 316 responsible for servicing a particularuser involved in a communication session. For example, if a firstenterprise user is being called by an external communication device,then the network boundary device 308 may initially receive the inboundcall, determine that the call is directed toward the first enterpriseuser, reference the server table 312 to identify the authoritativecommunications server 316 for the first enterprise user, and route theinbound call to the authoritative communications server 316. Likewise,communications between internal enterprise users (e.g., internalcommunication devices 348) may first be serviced by the originatinguser's authoritative communications server 316 during the originationphase of communications set-up. After the origination phase is complete,the authoritative communications server 316 of the terminating (orcalled) user may be invoked to complete the termination phase ofcommunications set-up. In some embodiments, the communications server316 for the originating and terminating user may be the same, but thisis not necessarily required. In situations where more than twoenterprise users are involved in a communication session, authoritativecommunications servers 316 for each of the involved users may beemployed without departing from the scope of the present invention.Additionally, the authoritative communications servers 316 for each usermay be in the same enterprise network 304 or in different enterprisenetworks 304, which are owned by a common enterprise but are separatedby the communication network 104.

Each communications server 316 may include a service selector 320, userpreferences 324, an object unpacker 328, and an object distributor 332.As can be appreciated, various modules of the communications server 316do not necessarily need to be implemented on the same server. Instead,the modules of the communication server 316 can be implemented in one ormore different servers or in different processors within the sameserver.

The service selector 320 provides the communication server 316 with theability to route user requests to the appropriate servers 336, 356, 364,372 within the network 304. Specifically, the service selector 320 maybe invoked in response to receiving a request to initiate acommunication session (e.g., an INVITE message in a SIP environment, anHTTP GET request, an inbound or outbound phone call, an email message, aShort Message Service (SMS) message, etc.) or a request for some othertype of information (e.g., a request for presence information such asvia a SUBSCRIBE message, a database query, etc.). Once invoked, theservice selector 320 may be configured to refer to the user preferences324 to determine which server is to be activated next. For example, thecommunication server 316 may receive a SIP message and the serviceselector 320 may refer to the user preferences 324 to determine whichserver 336, 356, 364, 372 is to receive the SIP message next. Morespecifically, the communication server 316 may be configured toestablish a chain of Back-to-Back User Agents (B2BUAs) in at least oneof a data and media path of a communication session by sequencing eachB2BUA into an application sequence one-by-one until the entireapplication sequence has been constructed.

The user preferences 324 for a communication server 316 contains theservice preferences for each user for which it is authoritative. In theexample of a communications service, the user preferences 324 may definewhich applications from the application server 336 should be invoked fora particular user's application sequence. Other types of userpreferences 324 may include User Interface preferences, data retrievalpreferences, presence information and privacy preferences, and the like.In some embodiments, the user preferences 324 may be in a table formatand may be provisioned by users and/or by administrative personnel. Theuser preferences 324 for a particular user are referenced by the serviceselector 320 to determine which, if any, services and what components ofthat service (e.g., sub-components 340, 360, 368, 376) should be invokedfor the user. Again referring to the communication-type service, theservice selector 320 may be configured to provide communication featuresdirectly into the communication session or determine an applicationsequence that will be invoked during set-up and used during thecommunication session.

The object unpacker 328 and object distributor 332 can be used by thecommunication server 316 to handle objects that are received from theservice warehouse 108. It should be appreciated that the object unpacker328 and object distributor 332 does not necessarily need to reside inthe same server, such as the communication server 316. For instance,both the object unpacker 328 and object distributor 332 can be residenton the system manager 364. As another example, the object distributor332 may be provided in the system manager 364 and each server thatreceives a sub-component (e.g., 336, 356, 372) may have its own objectunpacker 328.

In some embodiments, when the service warehouse 108 generates and sendsan object to the enterprise 304, the boundary device 308 may route themessage(s) containing the object to the communication server 316. As canbe seen in FIG. 6, an object 604 may comprise multiple constituent partssuch as a user portal sub-component 608, a set of deploymentinstructions 612, a call-processing sub-component 616, and a systemmanager sub-component 620. Each of these sub-components may specificallydesigned to be sent to and executed by a different server.

Accordingly, once received at the communication server 316, the objectunpacker 328 is configured to identify the various constituent parts ofthe object 604 and extract them from the object 604. In someembodiments, each sub-component of the object 604 may correspond to adifferent file, executable (e.g., instruction set), set of files, or setof executables. Unpacking the object 604 may simply correspond to theobject unpacker 328 extracting each file/executable corresponding toeach sub-component and temporarily storing the extracted file/executableat memory in the communication server 316.

The object unpacker 328 may then invoke the object distributor 332 todistribute the various sub-components to the appropriate servers 336,356, 364, 372 in accordance with the deployment instructions 612contained within the object 604. More specifically, the objectdistributor 332 may refer to the deployment instructions 612 and causethe call-processing sub-component 616 to be deployed to either theapplication server 336 (e.g., as an application sub-component 340) oranother part of the communication server 316. The user portalsub-component 608 may be deployed to the user portal 356 (e.g., as auser-portal sub-component 360). The system manager sub-component 620 maybe deployed to the system manager server 364 (e.g., as a system managersub-component 368). Once deployed by the object distributor 332, eachsub-component of the now-deployed object 604 can be executed by itscorresponding server. In some embodiments, the deployed sub-componentscan work in cooperation with one another to provide the fullfunctionality of a service.

As a non-limiting example, if the downloaded object 604 corresponds to anew communication application (e.g., a call-recording service, a dynamicdevice pairing service, a call-forwarding service, a voicemail service,a call log service, a caller identification service, an encryptionservice, etc.), when such a service is needed for a user during acommunication session, the user may be provided with the service by thecombined execution of each sub-component on each server 316, 336, 356,364, 372. More specifically, the call-processing sub-component 340stored on and executed by the application server 336 may be thesub-component 340 that is sequenced into the communication session as aB2BUA. The user portal sub-component 360 may enable a user to viewand/or configure the particular service, his/her preferences for theservice, and perform other functions related to the service (e.g., via aweb-based user interface). The system manager sub-component 368 mayenable the user and/or a system administrator (e.g., an administrator ofthe enterprise network 304) to control permissions and/or user access tothe service. Much like the user-portal sub-component 360, the systemmanager sub-component 368 may also be made available via a web-baseduser interface or the like.

As will be described in further detail herein, even though the object604 is deployed throughout the network 304 (e.g., for a customer 112),it may be possible to limit which users are allowed to access and usethe service or service version. In other words, users of the network 304may not necessarily have access to every service deployed in the network304 and some users may have access to different services or serviceversions than other users.

Although only one communication server 316, two application servers 336,one user portal server 356, and one system manager server 364 aredepicted, one skilled in the art will appreciate the one, two, three, ormore of any type of server can be provided and each server may beconfigured to provide one or more of the functions discussed herein.

The applications that can be included in a particular applicationsequence (e.g., via the communication server 316 and application server336) are generally included to accommodate the user's preferences 324and to provide communication services in accordance therewith. It shouldbe appreciated, however, that the user preferences, in some embodiments,are only within the bounds of services enabled for the user by thesystem administrator. Furthermore, some services assigned by theadministrator may not be capable of being disabled by the user based onuser preferences (e.g., mandatory call recording services assigned tothe user by the administrator may not be capable of being disabled).

Applications may vary according to media-type, function, and the like.Exemplary types of applications that can be provided via thesub-components 340 include, without limitation, an EC-500 application, acall setup application, a voicemail application, an email application, avoice application, a video application, a text application, aconferencing application, a call recording application, a communicationlog service, a security application, an encryption application, acollaboration application, a whiteboard application, mobilityapplications, presence applications, media applications, messagingapplications, bridging applications, and any other type of applicationthat can supplement or enhance communications. Additionally, one, two,three, or more applications of a given type can be included in a singleapplication sequence without departing from the scope of the presentinvention.

The communication server 316, application server 336, user portal server356, and system manager server 364 may correspond to but a few types ofservers that can be deployed in the network 304. Other servers 372 maybe provided that includes other sub-component types 376. Suitableexamples of such servers 372 and/or sub-component types 376 include,without limitation, management servers/agents, user-provisioned datastores, serviceability servers/agents, media processing servers/agents,Voice eXtensible Markup Language (VXML) stores, content stores, emailservers, voicemail servers, calendaring servers, conferencing servers,presence servers, and other types of servers known to provide particularservices to client devices. In some embodiments, the other servers 372may also be considered application servers 336, which provide one ormore applications for use in a communication session.

The internal communication devices 348 can be similar or identical tocommunication devices outside the network 304 except the internalcommunication devices 348 are provisioned, and often owned, by theenterprise administering the network 304. Illustrative types ofcommunication devices 348 include, without limitation, cellular phones,smartphones, laptops, Personal Computers (PCs), Personal DigitalAssistants (PDAs), digital phones, analog phones, and/or any other typeof capable phone, softphone or digital telephone. Examples of suitabletelephones include the 1600™, 2400™, 4600™, 5400™, 5600™, 9600™, 9620™,9630™, 9640™, 9640G™, 9650™, 9608™, 9611™, 9621™, 9641™, and QuickEdition™ telephones, IP wireless telephones (such as Avaya Inc.'s IPDECT™ phones), video phones (such as Avaya Inc.'s Videophone™), andsoftphones such as Avaya Flare™.

The data store 352 can be configured to includes enterprise subscriberinformation, such as name, job title, electronic address information(e.g., telephone number, email address, instant messaging handle, directdial extension, and the like), subscriber contact lists (e.g., contactname and electronic address information), other employee records, userpreferences 324, and the like. Information contained in the data store352 can be made available to one or more of the servers 316, 336, 356,364, 372 via various types of databases, servers, etc.

The various servers and components depicted in FIG. 3 may be implementedseparately (i.e., on different servers) or together (i.e., on a singleserver). In particular, two or more depicted components (e.g.,communication server 316 and application server 336) may be implementedon a single server without departing from the scope of the presentinvention. Thus, a single device may provide the functionality ofseveral components depicted separately in FIG. 3. As another example,the boundary device 308 and communication server 316 may be implementedon a single device.

As can be seen in FIG. 4, a particular sub-component deployed on aserver (e.g., a system manager sub-component 368 deployed on the systemmanager server 364) may correspond to a particular service type andversion of that service type. Several different service types ordifferent versions of the same service type can be deployed on a singleserver without departing from the scope of the present disclosure.Service types may be broadly defined (e.g., communication service, webservice, media service, etc.) or narrowly defined as a specific productoffered by a specific company (e.g., Avaya one-X® Communicator, Avayaone-X® Mobile, Avaya IP Office, AvayaLive™ Connect, Avaya Aura®Conferencing, Unified Messaging, Avaya Flare™ Experience, WebEx™Collaboration Services, speech analytics or data mining services such asthose provided by Aurix™, etc.). If sub-components of a common servicetype and version of that service type are provided on multiple differentservers, then those sub-components may cause the different servers tocooperate with one another in a way that seamlessly provides the commonservice type and version of that service type. Although not shown, itshould be appreciated that templates (see FIG. 7) can be administeredand assigned to users on the system manager 364. Those administeredtemplates can then be accessed by other servers to determine theservices/versions available to a given user.

As mentioned above, although a licensing sub-component is not depicted,a licensing sub-component can be also deployed, perhaps on a licensingserver. Other servers (e.g., system manager 364) can then check with thelicensing server to make sure the appropriate licenses are present toallow the user of that service. This license information could includethe number of users that can have the service assigned in the templateand system manager 364 would not allow more users to be assigned theservice than allowed by the licensing sub-component.

FIG. 5 depicts a communication system 500 in accordance with at leastsome embodiments of the present disclosure. The communication system 500comprises a shared communication service 512 that is made available to aplurality of different customers 508 a-N. One of the customers (e.g.,the third customer 508 c) may comprise a network 304 as depicted inFIGS. 3 and 4 with a plurality of physical servers on their premises.The servers may contain various communication services 512 in the formof sub-components that have been deployed from an object 604. One ormore of the communication services 512 (or any other type of service)can be shared with other customers 508 a, 508 b, 508N in accordance withembodiments of the present disclosure. Access to the sharedcommunication services 512 can be controlled at the customer's premisesvia the use of permission templates (see FIG. 7) in the same way that asingle enterprise or customer controls a per-user access to suchservices.

FIG. 5 also shows that a shared communication service 512 may residewithin the communication network 504 (e.g., as a cloud-basedcommunication service 512). The cloud-based communication service 512may be shared amongst two or more customers 508 in a securemanner—meaning that data from one customer will not be inadvertentlyshared with another customer. This security can be achieved bymaintaining secure or sensitive data locally at the customer's premisesor in an encrypted form if the data is maintained at a shared server ordata store 352.

Referring back to FIG. 6, it has already been described how an object604 may comprise a plurality of sub-components 608, 616, 620 and a setof deployment instructions 612 that, when followed or executed by theobject distributor 332, cause the various sub-components 608, 616, 620to be distributed to different servers in a network 304. In someembodiments, the deployment instructions 612, in addition to containinginstructions to deploy the object 604 once downloaded by a customer 112a-N, may also contain other information that described the object 604.More specifically, the deployment instructions 612 may also includeproduct documentation, user manuals, administration manuals,configuration guidelines, and any other type of data that describes theobject. In some embodiments, the deployment instructions 612 may beprovided in the form of one or more Enterprise Archive (EAR) filesand/or a Web application Archive (WAR) files. Likewise, thesub-components 608, 616, 620 can also be packaged in the object 604 asone or more EAR and/or WAR files.

An EAR file is a file format used by Java EE for packaging one or moremodules into a single archive so that the deployment of the variousparts of that single archive on a single server can occur simultaneouslyand coherently. Thus, once an EAR file of a particular sub-componentshas been directed to a particular server (e.g., a user-portalsub-component 360 has been deployed to the user portal server 356 inaccordance with the deployment instructions 612) the inherent nature ofthe EAR file will cause that particular sub-component to be deployedwithin the particular server seamlessly. Similar to an EAR file, a WARfile is a Java Archive (JAR) file used to distribute a collection ofJavaServer Pages, Java Servlets, Java classes, XML files, tag libraries,static web pages (HTML and related files) and other resources thattogether constitute a web application. The JAR file format used by theWAR file is an archive file format used to aggregate many Java classfiles and associated metadata and resources into one file to easilydistribute the application software or libraries on the Java platform.

In some embodiments, some of the sub-components of the object 604 may bepackaged as an EAR file while other sub-components of the object 604 maybe packaged as a WAR file. The type of file used for the sub-componentwill depend on the nature of the sub-component and the capabilities ofthe server that will eventually receive and deploy the sub-component. Asa non-limiting example, the call-processing sub-component 616 anddeployment instructions may be provided as EAR files whereas the systemmanager sub-component 620 and user portal sub-component 608 may beprovided as WAR files.

With reference now to FIG. 7, additional details of a template 700 thatcan be used to control per-user access to a service or per-customeraccess to a shared service 512 will be described in accordance with atleast some embodiments of the present disclosure. Although many detailsof the template 700 will be described in connection with controllingper-user access to services, it should be appreciated that teachingswith respect to per-user access can be easily applied to per-customeraccess to a shared service 512. Furthermore, although the template 700will be described with respect to a particular structure (e.g., a tablestructure), it should be appreciated that embodiments of the presentdisclosure are not so limited. More specifically, any type of datastructure or collection of data structures can be used to provide thefeatures of the template 700 discussed herein.

A template 700 may comprise a number of data fields that can beprovisioned by an end-user of a service and/or by a systemadministrator. The types of data fields that may be included in thetemplate 700 include, without limitation, a user identifier field 704and a plurality of service identifier fields 708, 712, 716.

The user identifier field 704 may identify a particular user in anenterprise network. For example, the user identifier field 704 mayidentify an employee of a customer 112 a-N, a customer of a business, anadministrator of a business, a group of employees, a group of customers,etc. The user identifier field 704 may also be used as an identifier ofcustomers if a communication service 512 is shared amongst a pluralityof different customers. Any string of numbers, characters, symbols,bits, or the like can be used to uniquely identify a user or customer inthe user identifier field 704. Examples of data that can be used toidentify a user include, without limitation, name, address, socialsecurity number, employee number, title, aliases (e.g., Address ofRecord (AoR)), etc. Examples of data that can be used to identify acustomer include, without limitation, company name, companyabbreviations, trademarks, numbers, etc.

Each service identifier fields 708, 712, 716 may correspond to adifferent service that is available to a user by virtue of the fact thata corresponding object 604 has been downloaded at the network 304 andthe required sub-components 608, 616, 620 have been distributed to theappropriate servers within the network 304. Once an object 604 isdownloaded and deployed at the network 304, a new field that identifiesthe service provided by the object 604 may be added to the template 700.

Default settings for user access to a service may be defined within thedownloaded object 604 (e.g., via the deployment instructions 612) and/orthey may be defined by rules created by a system administrator of thenetwork 304. As an example, the default settings for user access maydefine that no user is allowed access to the corresponding service.Representation of such a permission or lack thereof is depicted withrespect to the first communication service identified in the firstservice identifier field 708 for user 3.

As another example, the purchaser of the service from the servicewarehouse 108 (e.g., an administrator of network 304) may define whichusers will initially be allowed to use the service at the time ofpurchase. The object generator 216 at the service warehouse 108 mayconstruct the object 604 in accordance with the purchaser's request. Inparticular, the deployment instructions 612 may define that when thenewly created field is created in the template 700, only the usersidentified by the purchaser will have access to the service. All otherusers will not be allowed access to the service.

In the depicted table structure, the intersection between a user's rowand the service type's column may be used to define what accesspermissions the user is allowed to have with respect to the service.These permissions may be statically defined for a specific version ofthe service type. Alternatively, the permissions may comprise a wildcardvalue that defines the user is allowed to access a range of versions ofthe corresponding service type (e.g., any version earlier than versionX). Alternatively, the permissions may comprise a value that allows theuser to access any version or the latest version of a particularservice.

An advantage to using the template 700 is that different users of thesame enterprise and within the same network 304 can have differentaccess permissions for a service. As can be seen in the example of FIG.7, user 1 is allowed access to version 1.0 of communication service 2identified in field 712 whereas user 2 is allowed access to version 1.1of the same communication service. The field 712 also defines that groupA of users are not allowed any access to communication service 2 butgroup B is allowed access to version 3.1 of the same communicationservice. If there is a conflict between permissions defined individuallyfor a user versus permissions defined on a group basis for the same user(e.g., user 1 is a part of group A), then the permissions may becontrolled by the user's individually defined permissions. It may beadvantageous, however, to have certain conflicts be controlled by grouppermissions rather than individual permissions.

In some embodiments, the template 700 may be included in the userpreferences 324 and may be referred to by the service selector 320 whendetermining which service types and versions thereof a user is allowedto access. While the template 700 may be provided as part of the userpreferences 324, it may be possible to restrict a user from changing,editing, or writing data to some or all of the template 700. In otherwords, just because the template 700 is included in the user preferences324 does not necessarily make the entire template 700 available to theuser for editing. It may be possible, however, to allow the user to editportions of the template 700 within certain parameters that are eitherdefined by the network 304 administrator or the provider of the service(e.g., the operator of the service warehouse 108).

With reference now to FIG. 8, a data structure 800 used to allow thehierarchical definition and alteration of rules with respect to aservice will be described in accordance with at least some embodimentsof the present disclosure. The data structure 800 may be integrated intothe template 700 or it may be separate from the template 700. As anexample, if user 1 defines certain rules for communication service 1within data structure 800, those user-defined rules may either be copiedinto the intersection of user 1's row and field 708. Alternatively, apointer from the intersection of user 1's row and field 708 may point tothe corresponding location in data structure 800. The data structure 800may be included in the user preferences 324 or made available to theservice selector 320 remotely.

In some embodiments, the data structure 800 comprises hierarchicallystructured rules that enable a user to define any type of operatingparameter, rule, or permission with respect to a particular service aslong as it is within a permissible set of rules defined hierarchicallyby the provider of the service and the network 304 administrator. Morespecifically, the data structure 800 may comprise, for each serviceavailable within a network 304, a first layer of rules 804, a secondlayer of rules 808, a third layer of rules 812, a fourth layer of rules824, etc. In some embodiments, the first layer of rules 804 comprisesprovider-defined rules for the particular service, the second layer ofrules 808 comprises administrator-defined rules for the service, thethird layer of rules 812 comprises either user-defined rules 816,group-defined rules 820, or default rules 828 for the service, and thefourth layer of rules 824 comprises user-defined rules within the groupdefined rules 820.

The first layer of rules 804 may control options available to the lowerlayers of rules. As an example, if the provider defines that aparticular service can have one of three types of user interfaces (e.g.,three different skins for a web interface), then the administrator,users, and groups may be allowed to pick which of the three interfacesare to be used by a particular user when accessing the service.

The second layer of rules 808 further refine the first layer of rules804, but cannot broaden or extend beyond the first layer of rules 804.Continuing the above example, the administrator may define within theadministrator rules that only the first and second types of userinterfaces will be made available to users for the particular service.The administrator is not allowed to define a fourth interface typeoutside of the interface types defined by the provider.

Similar to the second layer of rules 808, the third layer of rules 812can further refine the second layer of rules 808 and first layer ofrules 804, but not broaden or extend beyond the first and second layerof rules 804, 808. Again continuing the interface example, the user maybe allowed to select between the first and second types of userinterfaces for the particular service. The user is not allowed to selectthe third interface because it has been restricted by the administratorand is not allowed to select a fourth interface because it has not beenenabled by the provider. The user rule 816 may specifically define theuser's selection for the service or it may refer to the default rules828 if the user has not defined their selection.

Much like the user rules 816, the group rules 820 and user rules 824 maybe used by users or groups of users to further refine a preference for aservice or an aspect of a service. It should be appreciated that therules defined within the data structure 800 are not limited to definingwhich interface a users employs to access a service. To provide anotheruse case for the data structure 800, a provider 804 may provide aservice to a customer 112 via a downloadable object 604. The service maycorrespond to a particular communication service type (e.g., dynamicdevice pairing, routing rules, EC500, etc.).

Consider, for example, that the particular communication service type isa first communication service and the first communication service has 10different versions. The latest versions (e.g., versions 9 and 10) aresupported by the service provider and the earliest versions (e.g.,versions 1 and 2) are no longer supported by the service provider. Inthis scenario, the provider may define within the first layer of rules804 that only versions 3-10 of the service are available. Continuingthis scenario, the administrator may only have purchased licenses toversions 7-9 for all users and may only have purchased a license toversion 10 for user 1 (e.g., a test user). The administrator can definewithin the second layer of rules 808 that versions 7-9 are available toall users of the network 304 whereas version 10 is only available touser 1. The administrator may also define the version of the servicethat will be used if a user does not select a service version for theiruse (e.g., via default rules 828). Any user or user group will then beallowed to select a specific version of the service among versions 7-9while user 1 will be allowed to select a specific version of the serviceamong versions 7-10. This enables the system administrator to test outnew versions of a service without having to purchase a license for theservice for every user in the network 304. It also allows each user tohave some latitude in selecting the version of the service that theyemploy. Thus, early adopter-type users are allowed to select newerversions of the service whereas late adopter-type users are allowed tokeep using the older version to which they have grown accustomed.

With reference now to FIG. 9, a method of receiving and fulfilling anorder for a service, such as a communication service, will be describedin accordance with at least some embodiments of the present disclosure.The method begins when an order for a service is received at the servicewarehouse 108 (step 904). In some embodiments, the order for a servicemay be received via the customer portal 208 (e.g., as a web-basedrequest).

The method continues with the object generator 216 analyzing the orderto determine parameters of the requested service (step 908).Specifically, the object generator 216 may determine from the parametersof the request what service has been requested, what version of theservice has been requested, what sub-components 228 are required tobuild the specified version of the service, what deployment instructions612 will be required to properly distribute the sub-components at thepurchaser's premises, how many licenses for the service have beenpurchased, which users will initially be permitted access to theservice, which users will initially be denied access to the service,provider rules for the service, and/or what types of servers thepurchaser has at their premises to support the service. Additionally, insome embodiments, the order may include metadata that describes one ormore aspects of the current service and/or the desired service. Forexample, an order may comprise metadata describing whether or not aparticular existing service or components of that service have certaincapabilities, such as High Availability (HA) capabilities. The metadatacontained within the order may help define which types of updates areavailable to or required by the customer to successfully update theservice.

Based on the analysis of the order, the object generator 216 preparesthe downloadable object 604 in accordance with the parameters of therequest (step 912). Specifically, the object generator 216 retrieves therequired sub-components 228 and builds the object 604. Thesub-components 228 may be packaged within the object 604 as one or moreof an EAR file and WAR file. Moreover, the deployment instructions 612may be packaged as an executable, EAR file, WAR file, text file, or thelike.

The retrieved sub-components may then be packaged into the object 604and prepared for transmission to the purchaser/customer 112 via thecommunication network 104 (step 916). In this step, the object generator216 may prepare the object 604 as one or more packets to be transmittedvia a communications channel established over the communication network104 between the service warehouse 108 and the customer 112. This mayinclude attaching the object 604 to one or more electronic messages(e.g., an email message, SMS message, or the like), packetizing theobject 604 into one or more packets that are capable of transmissionacross the communication network 104, or the like. The object generator216 and/or object delivery interface 212 may perform the packaging step.

Thereafter, the downloadable object 604 is delivered from the objectdelivery interface 212 to the purchaser via the communication network104 (step 920). As discussed above, this transmission step may includesending one or more electronic messages or packets that include some orall of the object 604.

With reference now to FIG. 10, a method of deploying and installing adownloadable object 604 will be described in accordance with embodimentsof the present disclosure. The method is initiated when a customer 112(e.g., a system administrator of one or more networks 304) provides anorder for a service, such as a communication service (step 1004). Afterthe order for the service has been placed, the steps of FIG. 9 areperformed and the customer 112 waits until the downloadable object 604is received at the network 304. The downloadable object 604 mayinitially be received at the boundary device 308 and may subsequently berouted to the communication server 316 where it is initially downloaded(e.g., stored in persistent or temporary memory on the communicationserver 316 or some other server 372) (step 1008).

The next step is for the object unpacker 328 and/or object distributor332 to analyze the deployment instructions 612 to determine the contentsof the object 604 and where each sub-component is to be directed withinthe network 304 (step 1012). Based on the deployment instructions 612,the various sub-components 608, 616, 620 of the object 604 are deployedto their corresponding servers 316, 336, 356, 364, 372 within thenetwork 304 (step 1016). Upon receiving the sub-component, the receivingserver will unpack the sub-component (e.g., unpack the EAR or WAR file)and install it within the server according to the instructions containedwithin the sub-component (step 1020). As a non-limiting example, theuser portal sub-component 608 may be deployed to the user portal server356 where it is stored as sub-component 360, the call-processingsub-component 616 may be deployed to the application server 336 where itis stored as sub-component 340, and the system manager sub-component 620may be deployed to the system manager server 364 where it is stored assub-component 368.

With reference now to FIG. 11, a method of customizing a downloadableobject 604 will be described in accordance with embodiments of thepresent disclosure. The method begins much like the method of FIG. 10with a customer 112 placing an order for a service, such as acommunication service (step 1104). The method continues with the objectgenerator 216 receiving information regarding the default features to beincluded in the communication service along with default rules 828 thatwill cause the service to behave in accordance with the default features(step 1108). In some embodiments, the default features may comprise aset of base rules and/or a range of rules that define acceptable orunacceptable use. Moreover, the default features may define whichsub-components are provided for the service unless specializedsub-component are requested or ordered.

The object generator 216 then compares the default features of theservice as determined in step 1108 with the features defined by thepurchaser in step 1104 to determine if a customized service is to begenerated specifically for this order (step 1112). In some embodiments,the purchaser may not define any special features for the service, inwhich case default features and default rules may be used for thegeneration of the object 604 (step 1120). In some embodiments, thepurchaser may define one or more customized aspects of the service thatare different from the default features of the service or the purchasermay define that certain users are to receive default features of theservice and other users are to receive customized features (step 1116).

When the purchased service comprises one or more customized features,the object generator 216 may retrieve the necessary sub-components andalter the sub-components themselves, deployment instructions 612 for theobject 604, provider rules 804, and/or default rules 828 for theservice. After the required features and rules have been selected, theobject generator 216 may build the downloadable object 604 in accordancewith the selected features (step 1124).

With reference now to FIG. 12, a method of deploying a service duringsystem run-time will be described in accordance with embodiments of thepresent disclosure. Although the method will be described in connectionwith a communication service, it should be appreciated that embodimentsof the present disclosure are not limited to communication services andmay be employed with the run-time deployment of any type of service suchas web-based services, media services, presence services, etc.

The method is initiated when a new service is received at thepurchaser's premises (e.g., some component of network 304) (step 1204).The object unpacker 328 and/or object distributor 332 may be configuredto identify which entities (e.g., users) within the network 304 are toreceive the service or be allowed access to the service once installed(step 1208). Prior to installing the various sub-components of theservice, the object distributor 332 may further determine whether anyidentified entity is currently using an older version of the servicethat has just been received (step 1212). More specifically, if a servicehas been upgraded or replaced by the newly-downloaded service, theobject distributor 332 may determine whether any user identified set toreceive the service is currently using an older version of that service.

If the query of step 1212 is answered negatively, then the methodproceeds with the object distributor 332 distributing the sub-componentsof the object 604 in the normal fashion and each server that receives asub-component is allowed to immediately install its correspondingsub-component and make the installed sub-component available to any userupon request (step 1228).

However, if the query of step 1212 is answered negatively, the methodcontinues with the object distributor 332 distributing thesub-components to the appropriate servers, but additional mechanisms areinvoked to ensure that the user(s) currently using the old version ofthe service are not interrupted. Specifically, the object distributor332 may distribute the various sub-components of the object 604 to theservers and the servers may install the new sub-components. At the sametime, the users currently using the old service version are allowed tocontinue using the service until they have completed its use (step1216). This may be accomplished in a number of ways. For example, theobject distributor 332 may instruct the server that receives thesub-component to download and install the sub-component but only use thesub-component for new requests for the service (step 1220). In otherwords, requests for a service that were received prior to the serverreceiving the sub-component may continue to be processed by the oldversion of the service (e.g., the old sub-component).

This may also be accomplished by informing the service selector 320 thatmessages received in connection with an old communication session (e.g.,a session established prior to receiving and downloading the object 604)should continue to be routed to the servers and sub-components that wereinitially invoked for the communication session. The service selectormay be instructed to only invoke the new sub-components forcommunication sessions established after the installation of thesub-components for the new service. This enables the new service to beused by users after they have finished using the old service, even ifthe old service version was in use during the download and installationof the sub-components of the new service (step 1224).

To provide a more concrete but non-limiting example, consider a newvoicemail system being received at the communication server 316 and thatnew voicemail system is to replace an older voicemail system. If anobject 604 containing the sub-components for the new voicemail system isreceived while a first user is currently using the old voicemail system,the object distributor 332 may still cause the necessary sub-componentsto be distributed to the corresponding servers where they are installed.This distribution and installation may occur while the first user iscurrently using the old voicemail system. A second user may try toconnect to the voicemail system while the first user is still using theold voicemail system and the service selector 320 may connect the seconduser with the new voicemail system even though the first user is stillusing the old voicemail system. This routing may occur due to theservice selector 320 referring to the user preferences 324 and theversion definitions provided in the template 700. This may also occurfor other users that were not using the old voicemail system while thenew voicemail system was being installed. Once the first user hascompleted his/her session with the old voicemail system, any newrequests from the first user to connect with the voicemail system willbe routed by the service selector 320 to the sub-components that providethe new voicemail system. Accordingly, the first user is not interruptedduring the installation of the new voicemail system and other users areimmediately able to access the new voicemail system once it has beeninstalled.

Another example scenario may occur whereby a user continues to use anolder version of a service even after a newer version of the sameservice has been installed. Specifically, as long as the user isassigned to use the older version rather than the newer version, thatuser may continue to use the older version instead of the newer version.

With reference now to FIG. 13, a method of upgrading a service will bedescribed in accordance with embodiments of the present disclosure. Themethod begins when a new service is received at a customer's premises(step 1304). The method continues with the object unpacker 328 and/orobject distributor 332 identifying the entities to receive the newservice (step 1308). This information may be defined within the object604 (e.g., via the deployment instructions 612) or it may be defined insome other location (e.g., within the system manager sub-component 620).Based on the information obtained in step 1308, the object distributor332 builds a template 700 or adds a field to an existing template 700such that the template 700 defines the permissions for the new serviceamong various entities within the network 304 (step 1312).

After the template 700 has been built or updated, the object distributor332 causes the new service to be distributed to the appropriate serversand installed therein such that the new service is made available withinthe network 304 (step 1316). Once installed, the service selector 320 iscapable of applying/enforcing the rules defined within the template 700as well as rules contained within any other data structure defining userpermissions and the like to any request for that service (step 1320). Asan example, if a user attempts to make an outgoing phone call after thenew service has been installed and the new service corresponds to a callrecording-type service, a speech-to-text service, a conversationalanalytics service, or the like, then the service selector 320 may, uponreceiving the message that initiates the call, route the message throughone or more sub-components 340, 360, 376 so that the new version of theservice is used for the user's outgoing call.

Over time the template 700 may be updated to add a user to the newservice, remove a user from the new service, add a group to the newservice, remove a group from the new service, etc. Changes to thetemplate 700 may be initiated via a user interacting with the systemmanager sub-component 368, the user portal sub-component 360, or anyother module within the network 304 that enables the viewing and editingof the template 700. If it is determined that a change to the template700 is required (step 1324), the system manager sub-component 368 and/orthe user portal sub-component 360 may instruct the communication server316 to update the corresponding fields in the template 700 if thetemplate 700 is being maintained at the communication server 316. In anyevent, the server responsible for managing the template 700 will beinstructed to update the template to reflect the change (step 1328).Thereafter, the method returns to step 1324.

In some embodiments, rather than returning directly to step 1324, anadditional step of removing/uninstalling may be performed. Specifically,after every user of a communication system has been migrated away froman old service version, the old service version and all associatedsub-components may be uninstalled from their corresponding servers.

In some embodiments, individual components may be upgraded during aservice upgrade rather than upgrading every component of the service.More specifically, if the original service has a first call-processingcomponent, a first user-portal component, and a first licensingcomponent (e.g., for 10 users), the original service may be upgraded toan upgraded service by simply updating one or more of the originalservice's components. As an example, if a customer only wants to upgradethe license part of their service, it may only be necessary to updatethe licensing component of the service to a second licensing component(e.g., for 20 users) without having to updating any other component ofthe service. It should be appreciated that depending upon whichcomponent of the service is upgraded, the costs associated with thatservice may need to be adjusted.

With reference now to FIG. 14, a method of hierarchically structuringattributes or rules for a service will be described in accordance withembodiments of the present disclosure. In some embodiments, the serviceand the object 604 representing the service is built and delivered to acustomer with a first level of attribute permissions 804 (step 1404).This first level of attribute permissions 804 may correspond to providerrules and may be default rules or a range or rules. In some embodiments,the purchaser may define during the ordering process that a second levelof attribute permissions 808 should be included in the object 604 (step1408). Alternatively, or in addition, the purchaser may define thesecond level of attribute permissions 808 after the object 604 isreceived at the network 304. Regardless of when the second level ofattribute permissions 808 are defined, the second level of attributepermissions 808 are created within the data structure 800 to furtherrefine or limit the first level of attribute permissions 804.

The method continues by determining if any more levels of attributepermissions will be incorporated into the data structure 800 to furtherlimit the second level of attribute permissions 808 (step 1412). If thisquery is answered affirmatively, a next level of attribute permissionsare defined for the service (step 1416). Steps 1412 and 1416 may berepeated as necessary until the desired number of hierarchical levelsare created. Once all desired levels of attribute permissions have beencreated, the method continues with the construction of the datastructure 800 that hierarchically orders the attributes based on thedefined levels (step 1420). Thus, the first level of attributepermissions define the broadest bounds of the attribute permissions(e.g., as a range or list of permissible attributes) and the lowerlevels of the attribute permissions further define the attributes orrules within the boundaries of all higher levels of attributepermissions.

In the foregoing description, for the purposes of illustration, methodswere described in a particular order. It should be appreciated that inalternate embodiments, the methods may be performed in a different orderthan that described. It should also be appreciated that the methodsdescribed above may be performed by hardware components or may beembodied in sequences of machine-executable instructions, which may beused to cause a machine, such as a general-purpose or special-purposeprocessor (GPU or CPU) or logic circuits programmed with theinstructions to perform the methods (FPGA). These machine-executableinstructions may be stored on one or more machine readable mediums, suchas CD-ROMs or other type of optical disks, floppy diskettes, ROMs, RAMs,EPROMs, EEPROMs, magnetic or optical cards, flash memory, or other typesof machine-readable mediums suitable for storing electronicinstructions. Alternatively, the methods may be performed by acombination of hardware and software.

Specific details were given in the description to provide a thoroughunderstanding of the embodiments. However, it will be understood by oneof ordinary skill in the art that the embodiments may be practicedwithout these specific details. For example, circuits may be shown inblock diagrams in order not to obscure the embodiments in unnecessarydetail. In other instances, well-known circuits, processes, algorithms,structures, and techniques may be shown without unnecessary detail inorder to avoid obscuring the embodiments.

Also, it is noted that the embodiments were described as a process whichis depicted as a flowchart, a flow diagram, a data flow diagram, astructure diagram, or a block diagram. Although a flowchart may describethe operations as a sequential process, many of the operations can beperformed in parallel or concurrently. In addition, the order of theoperations may be re-arranged. A process is terminated when itsoperations are completed, but could have additional steps not includedin the figure. A process may correspond to a method, a function, aprocedure, a subroutine, a subprogram, etc. When a process correspondsto a function, its termination corresponds to a return of the functionto the calling function or the main function.

Furthermore, embodiments may be implemented by hardware, software,firmware, middleware, microcode, hardware description languages, or anycombination thereof. When implemented in software, firmware, middlewareor microcode, the program code or code segments to perform the necessarytasks may be stored in a machine readable medium such as storage medium.A processor(s) may perform the necessary tasks. A code segment mayrepresent a procedure, a function, a subprogram, a program, a routine, asubroutine, a module, a software package, a class, or any combination ofinstructions, data structures, or program statements. A code segment maybe coupled to another code segment or a hardware circuit by passingand/or receiving information, data, arguments, parameters, or memorycontents. Information, arguments, parameters, data, etc. may be passed,forwarded, or transmitted via any suitable means including memorysharing, message passing, token passing, network transmission, etc.

While illustrative embodiments of the disclosure have been described indetail herein, it is to be understood that the inventive concepts may beotherwise variously embodied and employed, and that the appended claimsare intended to be construed to include such variations, except aslimited by the prior art.

What is claimed is:
 1. A method, comprising: receiving, by a processor,a request from a communication system comprising a plurality of users toobtain a downloadable pluggable service for at least one user of theplurality of users; in response to receiving the request, preparing, bythe processor, the downloadable pluggable service, wherein preparing thedownloadable pluggable service comprises identifying a first server anda second server that are associated with the at least one user,obtaining a first and second sub-component that are packaged into asingle object, wherein the first sub-component comprises instructionsfor operating the first server of the communication system, and whereinthe second sub-component comprises instructions for operating the secondserver of the communication system; and transmitting, by the processor,the single object to the communication system for the at least one userto access the downloadable pluggable service.
 2. The method of claim 1,further comprising: enabling a system administrator of the communicationsystem to specify customization of the downloadable pluggable servicewhen the downloadable pluggable service is requested.
 3. The method ofclaim 1, wherein a processor of the communication system enables a userto configure a data attribute of the downloadable pluggable service. 4.The method of claim 3, wherein the user configured data attribute iscontrolling over a data attribute not configured by the user.
 5. Themethod of claim 1, further comprising: enabling a system administratorof the communication system to specify customization of the downloadablepluggable service when the downloadable pluggable service is requested,wherein a processor of the communication system enables a user toconfigure a data attribute of the downloadable pluggable service, andwherein the user configured data attribute is controlling over a dataattribute not configured by the user.
 6. The method of claim 1, wherein,in the request, a system administrator of the communication system usesan eXtensible Markup Language (XML) to define data attributes of thedownloadable pluggable service.
 7. The method of claim 6, whereinHyperText Markup Language (HTML) code is prestored on a computerreadable medium of the communication system.
 8. The method of claim 7,wherein the downloadable pluggable service defines, in XML, to what dataattributes the HTML code applies to enable a communication systemprocessor to display the defined data attributes to the systemadministrator.
 9. The method of claim 1, wherein, in the request, asystem administrator of the communication system uses an eXtensibleMarkup Language (XML) to define data attributes of the downloadablepluggable service, wherein HyperText Markup Language (HTML) code isprestored on a computer readable medium of the communication system, andwherein the downloadable pluggable service defines, in XML, to what dataattributes the HTML code applies to enable a communication systemprocessor to display the defined data attributes to the systemadministrator.
 10. The method of claim 9, wherein the XML describingwhat prestored HTML code applies to the data attribute definitions hasless code-space than the described prestored HTML code.
 11. The methodof claim 1, wherein the downloadable pluggable service comprises a firsttemplate component assigned to a first user and a second templatecomponent assigned to a second user.
 12. The method of claim 11, whereinthe first template component controls services and settings of the firstuser, wherein the second template component controls services andsettings of the second user, and wherein at least one of the servicesand settings is different between the first user and the second user.13. The method of claim 11, wherein an administrator creates the firsttemplate component and the second template component.
 14. The method ofclaim 13, wherein the administrator creates the first template componentand the second template component prior to the receiving the requestfrom the communication system to obtain the downloadable pluggableservice.
 15. The method of claim 1, wherein the downloadable pluggableservice comprises attribute definitions to control at least one of aservice or setting, and wherein the attribute definitions require lesscode-space than code used to control the at least one of the service orsetting.
 16. A communication system, comprising: a server to provide aservice to communication devices of a plurality of users comprising aprocessor and a computer readable medium, coupled thereto, the computerreadable medium comprising enabled services, wherein the processor:receives a request from a communication system comprising a plurality ofusers to obtain a downloadable pluggable service for at least one userof the plurality of users; in response to receiving the request,prepares the downloadable pluggable service, wherein preparing thedownloadable pluggable service comprises identifying a first server anda second server that are associated with the at least one user,obtaining a first and second sub-component that are packaged into asingle object, wherein the first sub-component comprises instructionsfor operating the first server of the communication system, and whereinthe second sub-component comprises instructions for operating the secondserver of the communication system; and transmits the single object tothe communication system for the at least one user to access thedownloadable pluggable service.
 17. The communication system of claim16, wherein a file format of the downloadable pluggable service is oneof Java Archive (“JAR”) or Web Application Archive (“WAR”) file.
 18. Thecommunication system of claim 16, wherein a file format of thedownloadable pluggable service comprises multiple components comprisinga plurality of a call processing component, a service rule component, auser portal/interface component, and a system manager or administratorcomponent.
 19. The communication system of claim 16, wherein theinstructions of the first sub-component and the instructions of thesecond sub-component cause the processor to behave differently.
 20. Thecommunication system of claim 16, wherein the processor defines thedownloadable pluggable service with one or more templates, wherein theone or more templates comprise a user identifier field identifying asubset of the plurality of users and a plurality of service identifierfields, each of the plurality of service identifier fields correspondingto a different service that is available to the identified subset of theplurality of users, and wherein the one or more templates define accesspermissions for the identified subset of the plurality of users has withrespect to each of the different services corresponding to the pluralityof service identifier fields.